One way of transmitting a packet defined in accordance with an existing network protocol (e.g., a Fibre Channel packet) over the Ethernet network is to encapsulate such a packet in the payload portion of an Ethernet frame. As a result, the Ethernet frame with the packet encapsulated therein typically contains an EtherType field that indicates the type of the protocol of the encapsulated packet. For example, FIG. 1A illustrates an exemplary packet frame 100 in which an Internet Protocol (IP) packet is encapsulated or embedded. As can be seen, this frame 100 includes different fields, such as the Media Access Control (MAC) destination address 102 and the MAC source address 104, which identify the destination of the packet and the source of the packet, respectively, in the network. Usually following the MAC source address 104 is the EtherType field, i.e., EtherType 106, as shown in FIG. 1A. In this example, the EtherType 106 has a value of 0x0800, which indicates the encapsulated or embedded packet protocol is Internet Protocol version 4 (IPv4). Accordingly, the EtherType 106 is followed by an IPv4 header 108. Different values in the EtherType field identify different packet protocols encapsulated or embedded in the frame. For example, if the EtherType has a value of 0x8906, that means the protocol is Fibre Channel over Ethernet (FCoE), and if the EtherType is 0x86DD, the identified protocol is Internet Protocol version 6 (IPv6).
When a network packet, such as the one illustrated in FIG. 1A, is received at a device in the network, the device may delegate the packet processing task to some dedicated hardware, typically a particular protocol offload engine, if the received packet has an EtherType indicating the encapsulated packet is of a certain protocol. For example, a Transmission Control Protocol (TCP) Offload Engine (TOE) in a network interface card (NIC) may be dedicated for processing TCP/IP stacks. Likewise, converged network adapters (CNAs) may have dedicated hardware or firmware for processing FCoE packets. Alternatively, the network device may use a software module or software client, such as a driver program, to perform parsing and other processing functions of the received packet. Generally speaking, using dedicated hardware for processing packets can add costs, but is significantly faster and more efficient than the software approach. Therefore, the dedicated hardware solution is generally more desirable in storage area networks (SANs) where speed is an essential concern. In operation, both hardware and software approaches are utilized in a network device when parsing and processing a received network packet.
FIG. 1C is a flow chart illustrating an exemplary process of parsing a network packet in existing network devices. Starting at step 130, the device receiving the packet reads the EtherType field in the received packet to identify the packet type. Because the EtherType field is in a defined portion of the packet, i.e., usually following the MAC Source Address as shown in FIG. 1A, the device can quickly identify and read the EtherType from the receive packet. Then the device determines at step 132 whether the packet is of a known EtherType or network protocol. If so, the process proceeds to step 134, where the device offloads the processing of the packet to some dedicated hardware. Otherwise, the process continues to step 136, where the device sends the packet as a raw packet to a software client for further processing.
An existing packet frame as shown in FIG. 1A may be modified to include additional fields according to newly-developed standards and protocols. However, adding these fields may confuse the device when the device is trying to read the EtherType field from a received packet in the above-described process in FIG. 1C. For instance, the IEEE 802.1Q standard adds a tag header into the packet frame for storing additional information about the packet, such as a virtual local area network (VLAN) identifier. As illustrated in FIG. 1B, an exemplary packet frame 110 with an 802.1Q tag header inserted therein includes two additional fields, namely, an 802.1Q tag header type 116 and an 802.1Q tag header 118. The 802.1Q tag header 118 takes two bytes in the frame, as can be indicated by the 802.1Q tag header type 116. These fields are typically inserted between the MAC source address 114 and the EtherType 122. As a result, the EtherType 122 is no longer positioned right after the MAC source address 114. If the network device is not appropriately re-configured to be compatible with the 802.1Q protocol, it will not be able to recognize the inserted fields 116 and 118, as the device still expects to read the EtherType field following the MAC source address 114. As illustrated in FIG. 1C, the 802.1Q tag header type 0x8100 may be considered to be an unrecognized EtherType, as a valid EtherType is expected to be 0x0800. As a result, without reading the packet further to identify the EtherType 122, the receiving device would either drop the packet as an invalid packet or send the packet to a software client as a raw packet. In either case, the device will not be able to receive the benefit of hardware processing. Accordingly, there is a need for existing network devices to be able to recognize and read the EtherType field from any future-defined or modified packet frame, albeit how many additional fields, such as one or more tag headers, are inserted in the packet frame.